Add decode invoice and offer RPCs#164
Add decode invoice and offer RPCs#164benthecarman wants to merge 3 commits intolightningdevkit:mainfrom
Conversation
|
👋 I see @wpaulino was un-assigned. |
|
🔔 1st Reminder Hey @wpaulino! This PR has been waiting for your review. |
benthecarman
force-pushed
the
decode-inv
branch
from
01ebd59 to
7a0569d
Compare
Adds a new DecodeInvoice endpoint that parses a BOLT11 invoice string and returns its fields (destination, payment_hash, amount, timestamp, expiry, description, route_hints, features, currency, etc.), similar to lncli's decodepayreq needed for thunderhub and zeus. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Adds a new DecodeOffer endpoint that parses a BOLT12 offer string and returns its fields: offer_id, description, issuer, amount (bitcoin or currency), issuer_signing_pubkey, absolute_expiry, supported_quantity, blinded paths, features, chains, metadata, and expiry status. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
tnull
left a comment
tnull
left a comment
There was a problem hiding this comment.
I'm personally not the biggest fan of LND's approach of cramming everything into an RPC, so not quite convinced adding this via RPC is the right way to go? Why would we send an invoice we got from the server back to the server (via network/RPC) to then have the server send the decoded data back?
Alternative approaches we could consider:
- Offer local invoice utilities as a
clitool that allows invoice/offer decoding and manipulation. Could be nice for UNIX-style comparability of tools. - Have server endpoints return more comprehensive responses that give immediate access to all important fields.
Did you consider any of these before?
Yeah I agree but sadly seems like a lot of applications find this endpoint useful.
Considered this but doesn't really solve most usecases. Something like thunderhub or zeus don't use the cli, they call the RPC so wouldn't really be helpful. (maybe it is worth shortcutting in the cli tho?)
Did a little of that with #163 but that only works for the receive case. Seems like applications are using this for the send case. |
Hmm? Presumably then to validate the invoice before paying? Rather than exposing an RPC for decoding, would it make sense to add more validation before sending on our end? Or maybe I'm misunderstanding what they're looking for? |
more so to get the amount, destination, expiry, etc |
tnull
left a comment
tnull
left a comment
There was a problem hiding this comment.
more so to get the amount, destination, expiry, etc
Alright. I guess if we want to add it we should double check that we properly escape all user-provided strings like descriptions etc. So that a malicious user could never have us, e.g., interpret control characters in CLI, etc?
Escape Unicode bidirectional override/embedding/isolate characters (U+200E–U+2069) as \uXXXX in CLI JSON output to prevent them from silently reordering displayed text in terminal emulators. serde_json already handles ASCII control characters (U+0000–U+001F), but bidi characters pass through unescaped. The sanitization is done in the CLI display layer, not the server, so the server returns raw data faithfully. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
Looks like serde handles some control characters already but added handling for the remaining. Will help with other rpcs for like if someone did something with their alias or something. |
3 participants
Adds a new DecodeInvoice endpoint that parses a BOLT11 invoice string and returns its fields (destination, payment_hash, amount, timestamp, expiry, description, route_hints, features, currency, etc.), similar to lncli's decodepayreq needed for thunderhub and zeus. Does the same for bolt 12 offers as well.